iT邦幫忙

2026 iThome 鐵人賽

DAY 4
0
AI Engineering

從 4,343 筆職缺到 AI Engineer:MLOps × GenAI Engineering 雙主軸實戰系列 第 4

Day 04:從職缺任務到學習地圖——您走哪條路?

  • 分享至 

  • xImage
  •  

站在哪裡往前走

三天下來我們確認了:市場要什麼(Day 02)誰負責什麼(Day 03)。今天是第一部曲的收尾,也是我覺得最實用的一篇——把職缺梳理成您能照著走的路

今天要解決的問題

「我知道要學 MLOps 了,然後呢?」

這是我最常思考的問題,而多數答案都不見得符合實際,因為多半收到的是技術清單:Docker、K8s、MLflow、Airflow、Terraform……看起來很完整,但沒有回答到我期待的三個關鍵問題:

  1. 順序:先學哪個?(學錯順序會卡很久,例如還不會 Docker 就學 K8s)
  2. 深度:學到什麼程度算夠?(每個都要精通的話,我怕我兩年也走不完)
  3. 止損點:什麼可以先不學?(這題最少人回答,但卻關係到時間緊迫的策略取捨)

今天這篇就試著回答這三個問題。

📊 職缺訊號

學習順序應該按任務訊號的頻率 × 您的缺口排序,而不是依照「技術難度」排序。同樣是 MLOps,平臺與基礎設施出現在 58.5% 的職缺、模型版本與實驗管理只有 7.2%——不是後者不重要,而是當你時間有限時,前者能讓你先拿到面試


一、現象:三條轉職路線,起點不同

絕大多數要進這兩個職務的人,來自三個地方。您的既有優勢待補缺口完全不同:

三條主流轉職路線的優勢與缺口

圖 4-1:三條主流轉職路線的既有優勢與待補缺口(依 2026 年職缺任務訊號與常見團隊分工整理的示意性歸納)。綠色是可直接遷移的優勢,紅色是本系列要補的缺口。

路線 A:後端/DevOps → MLOps/LLMOps。 您已經有容器、CI/CD、監控、API 服務的底子——這是最短的路。您缺的不是工程能力,是「ML 特有的那些會故障的地方」:資料會漂移、特徵在訓練與線上會不一致、模型會無聲失效。Day 09、11、14 是你的重點。

路線 B:資料科學家 → MLOps/LLMOps。 您懂模型與資料,缺的是工程紀律與系統思維:容器、K8s、IaC、SLO。這條路的難處不是學不會,是心態轉換——從「這個模型指標更好」轉換成「這個系統半夜壞了誰處理」。Day 12、13、15 是你的重點。

路線 C:前/後端 → 生成式 AI 應用。 您會做系統整合,缺的是LLM 的行為特性:它會胡說、輸出不確定、每次呼叫都在花錢、還可能被使用者的輸入騙走。Day 07、18–20、24–25 是你的重點。

二、原理:學習順序的三個排序原則

有了缺口清單,接下來是排序。我們梳理成三個原則:

原則一:能不能動手,優先於懂不懂原理。 先讓一個東西在電腦上跑起來,再回頭理解為什麼。這是因為跑過比較容易記住。所以 Day 05 會先提供工程基礎,Day 06、07 才補理論。

原則二:先學「會被別人依賴」的,再學「只有自己用到」的。 容器化的優先序高於實驗追蹤,因為前者是別人接您工作的介面,後者是自己的工作習慣。這也對應了任務訊號的高低。

原則三:先建立回饋迴路,再談優化。 監控與評測要早於效能最佳化。如果連自己有沒有變好都不知道,又該如何談優化。也因此會安排 Day 14 談監控, Day 15 再談成本優化;Day 20 會談評測、Day 23 再談微調。

三、動手:30 天怎麼取用

30 天連載路線圖

圖 4-2:30 天連載路線圖(依任務訊號配比規劃的示意排程)。Day 08 分流、Day 24 合流。

完整版: 照順序走,Day 28 的綜合專題會把前 27 天串起來。

主軸一速成(時間有限、想轉 MLOps): Day 01–04 → 05–06 → 08–15 → 24、26、27 → 28–30。可跳過 Day 07、16–23 的細節,但 Day 18 與 Day 21 建議略讀,因為您未來要支援的就是這些系統。

主軸二速成(時間有限、想做生成式 AI 應用): Day 01–04 → 05、07 → 16–23 → 24–27 → 28–30。可跳過 Day 09–11,但 Day 12–14 建議略讀——不懂部署與監控的應用工程師,做出來的東西上線也不好控制。

週末版(平日沒空): 每個週末處理一個部曲,六週走完。優先做每篇的「動手」段落,「取捨」段落當睡前讀物。

主管/教學者版: Day 01–04(為什麼要投資這個能力)+ Day 29(怎麼驗收)+ Day 30(怎麼規劃團隊路徑)。中間 25 天當作能力清單的細目。

搭配一個可勾選的能力檢核,每完成一項就打勾——這份清單直接對應面試會問的東西

【共同地基】
□ 能寫一個 multi-stage Dockerfile 把服務打包成 500MB 以下的映像
□ 能說明 .env 與金鑰管理的正確做法,且從不把金鑰寫進程式碼
□ 能講清楚「訓練/驗證/測試」為什麼要切、切錯會怎樣
□ 能估算一次 LLM 呼叫的成本,並說出哪一段最貴

【主軸一 MLOps】
□ 能用 MLflow 追蹤實驗並註冊模型,服務端以 alias 取用
□ 能寫一條含品質門檻的 CI 流程,模型沒過門檻不得上線
□ 能在本地 kind 叢集部署服務並設定 HPA
□ 能對 API 壓測並讀懂 P50/P95/P99,據此訂 SLO
□ 能用 PSI 或 KS 檢定偵測漂移,並說明門檻怎麼定

【主軸二 生成式 AI】
□ 能建一個含混合檢索與來源引用的 RAG 系統
□ 能手刻一個具工具呼叫與迭代上限的 ReAct agent
□ 能建 20 題以上的評測集,並算出 LLM 評審與人工標註的一致性
□ 能說明提示注入的四層防禦,並實作其中至少兩層
□ 能判斷一個需求該用微調、RAG 還是提示工程,並說出理由

四、取捨:什麼可以先不學

以下這些,在您拿到第一份相關工作之前,可以先不碰,在策略上設定明確的止損點

先不學 為什麼 什麼時候再學
自建 Kubernetes 叢集 先求會用(部署、除錯),建叢集是平臺團隊的事,還不急 進入約有 8 人以上規模團隊、要做內部平臺時
從頭訓練大模型 幾乎沒有職缺要求,成本也不是個人負擔得起,這是市場說的不是我說的 進入模型研發團隊時(極少數)
全參數微調 90% 的客製需求用 RAG 或 LoRA 就能解 有明確風格/格式需求且已試過提示工程後(Day 23)
多代理框架(AutoGen、CrewAI 等) 多數需求用確定性工作流更穩、更便宜 單一代理已經做好,且確實遇到需要協作的場景(Day 22)
分散式訓練(DDP/FSDP) 對應職缺比例極低 要訓練 10B 以上模型時
各家雲端的專屬服務認證 觀念相通,工具可換;先學開源版本理解原理 確定要進的公司用哪一朵雲之後

⚠️ 但這三件事不能省

可重現、監控、評測。 這三項在每份職缺裡都不是最顯眼的關鍵字,卻是資深與初階的實質差別。它們的共同點是:做了不會有人稱讚,沒做遲早會出事。


今日小結

  • 三條轉職路線起點不同:後端/DevOps 缺「ML 特有的坑」、資料科學家缺「工程紀律」、前後端缺「LLM 的行為特性」。
  • 學習排序三原則:能動手優先於懂原理先學會被依賴的先建立回饋迴路再優化
  • 30 天可依主軸速成取用,Day 08 分流、Day 24 合流;交會段(24–27)都要讀別跳過。
  • 明確的止損點:自建叢集、從頭訓練、全參數微調、多代理框架、分散式訓練、雲端專屬認證——優先排序往後,在此之前您還有更重要的事。
  • 不能省的三件事:可重現、監控、評測

明天預告

第一部曲結束,明天進入地基。我們從最實際的地方開始:您的開發環境。Python 環境、Git 在 ML 專案的特殊性(大型檔案、資料、金鑰)、第一個 Dockerfile,以及一個太多人踩的坑——把 API 金鑰推上 GitHub。


上一篇
Day 03:兩個職務的責任界面——誰該負責什麼
系列文
從 4,343 筆職缺到 AI Engineer:MLOps × GenAI Engineering 雙主軸實戰4
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言